Re: [Python-Dev] Too many Python accounts

[Michael Foord]

Martin v. Löwis wrote:

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.

  
No, the whole point of delegation is that I can use voidspace.org.uk as 
my openid - backed with any provider I want. I can then use 
voidspace.org.uk as my openid and not be tied to any provider.


I'm afraid the PyPI implementation of openid is useless to me too - I 
want to use voidspace.org.uk as my openid but it doesn't let me.


All the best,

Michael


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/fuzzyman%40voidspace.org.uk
  



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

[Antoine Pitrou]

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


Regards

Antoine.


___
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 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 :)

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

[Georg Brandl]

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.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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 4:02 AM, Terry Reedy  wrote:
> 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.

Ok. Fair enough, I'll work with them this way.

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

[Georg Brandl]

Martin v. Löwis schrieb:
>> 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.

BTW, I noticed that the "cancel build" and "cancel all builds" buttons result
in unhandled exceptions.  (One build is cancelled nevertheless, so for
"cancel build" it's just an inconvenience.)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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

[David Cournapeau]

On Sun, Nov 15, 2009 at 10:32 PM, Tarek Ziadé  wrote:

>
> Ok. Fair enough, I'll work with them this way.

Although packagers should certainly fix the problems they introduce in
the first place, the second suggestion in the bug report would be
useful, independently on how linux distributions package things.

Especially if the data can be obtained for every build (autoconf and
VS-based), this would help packages which use something else than
distutils for their build.

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

>> 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.
>>
>>   
> No, the whole point of delegation is that I can use voidspace.org.uk as
> my openid - backed with any provider I want. I can then use
> voidspace.org.uk as my openid and not be tied to any provider.

I'm fairly skeptical that you actually do use voidspace.org.uk.
I can believe that this is what you type into the openid field -
but the ID that is validated to the relying party is
http://fuzzyman.myopenid.com/.

So when you change the provider (and hence the openid.delegate
value), you will have to create new accounts for all services
that you use, right?

> I'm afraid the PyPI implementation of openid is useless to me too - I
> want to use voidspace.org.uk as my openid but it doesn't let me.

See above - the services may let you *enter* that string, but it
isn't your 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

[Michael Foord]

Martin v. Löwis wrote:

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.

  
  

No, the whole point of delegation is that I can use voidspace.org.uk as
my openid - backed with any provider I want. I can then use
voidspace.org.uk as my openid and not be tied to any provider.



I'm fairly skeptical that you actually do use voidspace.org.uk.
I can believe that this is what you type into the openid field -
but the ID that is validated to the relying party is
http://fuzzyman.myopenid.com/.

So when you change the provider (and hence the openid.delegate
value), you will have to create new accounts for all services
that you use, right?
  


Well, when I login my registered ID is www.voidspace.org.uk and *not* 
fuzzyman.myopenid.com - so I believe you are incorrect (and in fact this 
very point was touted as one of the advantages of openid - that your 
account is independent of your provider and that you *can* change 
provider whilst retaining the same id).


myopenid *does* the validation, but my registered openid is 
www.voidspace.org.uk and I *should* be able to change provider without 
creating a new account.


Michael

  

I'm afraid the PyPI implementation of openid is useless to me too - I
want to use voidspace.org.uk as my openid but it doesn't let me.



See above - the services may let you *enter* that string, but it
isn't your openid.

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

[Martin v. Löwis]

> Well, when I login my registered ID is www.voidspace.org.uk and *not*
> fuzzyman.myopenid.com - so I believe you are incorrect (and in fact this
> very point was touted as one of the advantages of openid - that your
> account is independent of your provider and that you *can* change
> provider whilst retaining the same id).

On the wire (between relying party and provider), voidspace.org.co.uk
does never appear. From the OpenID 1.1 specification:

# Now, when a Consumer sees that, it'll talk to
# http://www.livejournal.com/openid/server.bml and ask if the End User
# is exampleuser.livejournal.com, never mentioning www.example.com
# anywhere on the wire.

So all I (as a relying party) get verifyied is fuzzyman.myopenid.com.
Why should I trust that voidspace.org.uk is actually a valid ID?
Can't you then produce hundreds of IDs, all delegating to the same
identity?

IOW, why should I (as a relying party) pay any attention to the ID
that you entered, rather than to what I get actually validated?

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

[Python-Dev] global statements outside functions/methods should raise SyntaxError

[Ezio Melotti]

Python currently accepts global statements at the top level:

global foo



Beside being a meaningless operation, this might lead unexperienced
user to make mistakes like:

foo = 5
global foo # make foo global
def func():

...   print foo # access the global foo
...

func()

5

# it works!


"global foo" should raise a SyntaxError, similarly to what already
happens with "return":

return foo

 File "", line 1
SyntaxError: 'return' outside function


I opened an issue on the tracker (http://bugs.python.org/issue7329)
and Benjamin suggested to discuss this here.
The test he mentioned is in test_global.py:

   def test4(self):
   prog_text_4 = """\
global x
x = 2
"""
   # this should work
   compile(prog_text_4, "", "exec")

It just says that "it should work" but it doesn't say /why/.

Any thoughts?

___
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] global statements outside functions/methods should raise SyntaxError

[Michael Foord]

Ezio Melotti wrote:

Python currently accepts global statements at the top level:

global foo



Beside being a meaningless operation, this might lead unexperienced
user to make mistakes like:

foo = 5
global foo # make foo global
def func():

...   print foo # access the global foo
...

func()

5

# it works!


"global foo" should raise a SyntaxError, similarly to what already
happens with "return":

return foo

 File "", line 1
SyntaxError: 'return' outside function


I opened an issue on the tracker (http://bugs.python.org/issue7329)
and Benjamin suggested to discuss this here.
The test he mentioned is in test_global.py:

   def test4(self):
   prog_text_4 = """\
global x
x = 2
"""
   # this should work
   compile(prog_text_4, "", "exec")

It just says that "it should work" but it doesn't say /why/.


Well, personally I think it would be a good thing if this raised an 
exception during bytecode compilation - but it would fall under the 
moratorium and have to wait a few years.


On the other hand it should be easy to get PyLint to include a checker 
for this and they are very responsive to feature requests.


All the best,

Michael



Any thoughts?

___
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/fuzzyman%40voidspace.org.uk 




--
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] global statements outside functions/methods should raise SyntaxError

[Benjamin Peterson]

2009/11/15 Michael Foord :
> Well, personally I think it would be a good thing if this raised an
> exception during bytecode compilation - but it would fall under the
> moratorium and have to wait a few years.

It could probably be considered a bug, though, since the global
statement in that case silently has absolutely no effect.


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

Re: [Python-Dev] Too many Python accounts

[Carey Tilden]

On Sun, Nov 15, 2009 at 11:31 AM, "Martin v. Löwis"  wrote:
>
> > Well, when I login my registered ID is www.voidspace.org.uk and *not*
> > fuzzyman.myopenid.com - so I believe you are incorrect (and in fact this
> > very point was touted as one of the advantages of openid - that your
> > account is independent of your provider and that you *can* change
> > provider whilst retaining the same id).
>
> On the wire (between relying party and provider), voidspace.org.co.uk
> does never appear. From the OpenID 1.1 specification:
>
> # Now, when a Consumer sees that, it'll talk to
> # http://www.livejournal.com/openid/server.bml and ask if the End User
> # is exampleuser.livejournal.com, never mentioning www.example.com
> # anywhere on the wire.
>
> So all I (as a relying party) get verifyied is fuzzyman.myopenid.com.
> Why should I trust that voidspace.org.uk is actually a valid ID?

Since the user entered voidspace.org.uk, they presumably believe it's an
address they control.  You have to assume they delegated to another
provider on purpose.

> Can't you then produce hundreds of IDs, all delegating to the same
> identity?

Yes.

> IOW, why should I (as a relying party) pay any attention to the ID
> that you entered, rather than to what I get actually validated?

Because the user entered the value they wanted as their identity.  This is
the reason delegation even exists in the spec.  In fact, the very next line
after the section you quoted is:

# The main advantage of this is that an End User can keep their Identifier
# over many years, even as services come and go; they'll just keep
# changing who they delegate to.

If the provider dictates the identity, as you keep insisting, that sentence
makes no sense whatsoever.  The value entered as the identifier is the
identifier you should use.  Otherwise, what's the point of delegation at all?

> 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/carey.tilden%40gmail.com
___
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] global statements outside functions/method s should raise SyntaxError

[Antoine Pitrou]

Benjamin Peterson  python.org> writes:
> 
> 2009/11/15 Michael Foord  voidspace.org.uk>:
> > Well, personally I think it would be a good thing if this raised an
> > exception during bytecode compilation - but it would fall under the
> > moratorium and have to wait a few years.
> 
> It could probably be considered a bug, though, since the global
> statement in that case silently has absolutely no effect.

Indeed, and it's not like other implementations would be at a disadvantage if
they didn't implement this error.

Warning that the construct is meaningless can be helpful, especially for
refugees from other languages.

Regards

Antoine.


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

[skip]

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

I've never found OpenID at all intuitive to use.  Are there instructions on
pypi.python.org which detail the steps necessary to use OpenID to login?  I
saw the "Claim OpenID" link on my PyPI profile page.  So now I have an
OpenID URL.  What am I supposed to do with that?  If I visit that URL it
downloads a small bit of XML.

I've tried using my Yahoo! and Luanchpad OpenIDs for other sites in the
past.  I've never successfully logged into any website with them, at least
not as far as I can recall.  I realize that maybe this is something that
just doesn't click with me (maybe I'm an OpenID Luddite), but it seems to me
that OpenID needs to be a bit easier (or obvious?) to use if it's to become
some sort of de facto standard login mechanism.

Skip
___
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] global statements outside functions/methods should raise SyntaxError

[MRAB]

Benjamin Peterson wrote:

2009/11/15 Michael Foord :

Well, personally I think it would be a good thing if this raised an
exception during bytecode compilation - but it would fall under the
moratorium and have to wait a few years.


It could probably be considered a bug, though, since the global
statement in that case silently has absolutely no effect.


It wouldn't be adding a new feature, but it would be changing the
behaviour of programs that currently have 'global' outside a function.

Perhaps, due to the moratorium, there should be a warning before it's
actually corrected.
___
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] global statements outside functions/methods should raise SyntaxError

[Terry Reedy]

Ezio Melotti wrote:

Python currently accepts global statements at the top level:

I opened an issue on the tracker (http://bugs.python.org/issue7329)
and Benjamin suggested to discuss this here.
The test he mentioned is in test_global.py:

   def test4(self):
   prog_text_4 = """\
global x
x = 2
"""
   # this should work
   compile(prog_text_4, "", "exec")

It just says that "it should work" but it doesn't say /why/.

Any thoughts?


I make the same suggestion a couple of years ago, either this list or 
Py3k list, after newby reported 'problem' on python-list expecting 
module-level global to do something. Guido rejected it on the basis that 
he wanted to minimized differences between module code and function code.


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

[Brett Cannon]

On Sat, Nov 14, 2009 at 20:01, Benjamin Peterson  wrote:
> 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.

Well, it happens to be used by the standard library in linecache, but
not all external uses of it necessarily tie into linecache (e.g.
importlib uses detect_encoding() in some non-critical code). Might
just have to live with sub-optimal code.

-Brett
___
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/15 Brett Cannon :
> On Sat, Nov 14, 2009 at 20:01, Benjamin Peterson  wrote:
>> 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.
>
> Well, it happens to be used by the standard library in linecache, but
> not all external uses of it necessarily tie into linecache (e.g.
> importlib uses detect_encoding() in some non-critical code). Might
> just have to live with sub-optimal code.

Well, what I mean is that we'd do:

def _detect_encoding():

in linecache and then "from linecache import _detect_encoding as
detect_encoding" in tokenize.py.



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

Re: [Python-Dev] Too many Python accounts

[Martin v. Löwis]

>> Can't you then produce hundreds of IDs, all delegating to the same
>> identity?
> 
> Yes.

But then, users can easily create as many fake accounts as they want to.
This is not something I want to happen (it's still possible to setup
fake accounts, but it should be more difficult for the average script
kiddy).

> If the provider dictates the identity, as you keep insisting, that sentence
> makes no sense whatsoever.  The value entered as the identifier is the
> identifier you should use.  Otherwise, what's the point of delegation at all?

It may help users to remember their openid more easily, and always fill
in the same text into the login box.

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 (was Re: PyPI comments and ratings, *really*?)

[Martin v. Löwis]

> I've never found OpenID at all intuitive to use.  Are there instructions on
> pypi.python.org which detail the steps necessary to use OpenID to login?  I
> saw the "Claim OpenID" link on my PyPI profile page.  So now I have an
> OpenID URL.  What am I supposed to do with that?  If I visit that URL it
> downloads a small bit of XML.
> 
> I've tried using my Yahoo! and Luanchpad OpenIDs for other sites in the
> past.  I've never successfully logged into any website with them, at least
> not as far as I can recall.  I realize that maybe this is something that
> just doesn't click with me (maybe I'm an OpenID Luddite), but it seems to me
> that OpenID needs to be a bit easier (or obvious?) to use if it's to become
> some sort of de facto standard login mechanism.

That's indeed what PyPI attempts to do. At the "claim openid" place,
follow the Launchpad link. It should guide you through the procedure.

Then, when you want to login, again follow the Launchpad link on the
front page.

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] global statements outside functions/methods should raise SyntaxError

[Guido van Rossum]

On Sun, Nov 15, 2009 at 12:38 PM, Terry Reedy  wrote:
> Ezio Melotti wrote:
>>
>> Python currently accepts global statements at the top level:
>>
>> I opened an issue on the tracker (http://bugs.python.org/issue7329)
>> and Benjamin suggested to discuss this here.
>> The test he mentioned is in test_global.py:
>>
>>   def test4(self):
>>       prog_text_4 = """\
>> global x
>> x = 2
>> """
>>       # this should work
>>       compile(prog_text_4, "", "exec")
>>
>> It just says that "it should work" but it doesn't say /why/.
>>
>> Any thoughts?
>
> I make the same suggestion a couple of years ago, either this list or Py3k
> list, after newby reported 'problem' on python-list expecting module-level
> global to do something. Guido rejected it on the basis that he wanted to
> minimized differences between module code and function code.

That example should work because you could pass it to exec()/eval()
with separate dicts for locals and globals:

$ python3.0
Python 3.0 (py3k:67506, Dec  3 2008, 10:12:04)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> glo = {}
>>> lo = {}
>>> so = 'global x; x = 2'
>>> co = compile(so, '', 'exec')
>>> exec(co, glo, lo)
>>> glo['x']
['x']
>>> exec('x = 3', glo, lo)
>>> glo['x']
2
>>> lo['x']
3
>>>

-- 
--Guido van Rossum (python.org/~guido)
___
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

[Brett Cannon]

On Sun, Nov 15, 2009 at 05:31, 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.

+1 from me as well. Python is designed to run as a whole. If they
choose to ignore our design decisions they do so at their own peril.

Now if you want to put the time in, Tarek, to make sure distutils can
be removed from the stdlib and have everything still work so the linux
distros can add distutils to python-devel that's fine, but once again,
they are the ones mucking around with things in a way we did not
design for, so only do it if you really want to.

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

[Daniel Stutzbach]

On Sun, Nov 15, 2009 at 2:44 PM, "Martin v. Löwis" wrote:

> But then, users can easily create as many fake accounts as they want to.
>

Why not do something more robust, then?  For example, when a user enters an
OpenID that hasn't been seen by PyPi before, make them enter a CAPTCHA.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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]

Martin v. Löwis wrote:

Can't you then produce hundreds of IDs, all delegating to the same
identity?
  

Yes.



But then, users can easily create as many fake accounts as they want to.
This is not something I want to happen (it's still possible to setup
fake accounts, but it should be more difficult for the average script
kiddy).

  


This doesn't seem to be a problem for all the other sites I use my 
openid with. Why not allow users to login with their own openid, but 
only allow one account to refer back to the same delegated account?


Michael


If the provider dictates the identity, as you keep insisting, that sentence
makes no sense whatsoever.  The value entered as the identifier is the
identifier you should use.  Otherwise, what's the point of delegation at all?



It may help users to remember their openid more easily, and always fill
in the same text into the login box.

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 (was Re: PyPI comments and ratings, *really*?)

[skip]

Martin> That's indeed what PyPI attempts to do. At the "claim openid"
Martin> place, follow the Launchpad link. It should guide you through
Martin> the procedure.

Well, since I use Google a lot more I'd prefer to use that.  If I click the
Google OpenID link I now get

OpenID is already claimed

Martin> Then, when you want to login, again follow the Launchpad link on
Martin> the front page.

That seems to work, but I'm not sure how.  Doesn't seem to use cookies.  The
Google OpenID link leads to

http://pypi.python.org/pypi?:action=login&provider=Google

which contains nothing about me.  I saw a pypi.python.org cookie which
expires "On Quit", so I restarted Camino and verified there were no
pypi.python.org cookies, then clicked the Google OpenID link.  It still
works.  I must be missing something obvious...

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

> This doesn't seem to be a problem for all the other sites I use my
> openid with.

Perhaps they don't care about fake accounts at all? That would, in
particular, be the case if they accept arbitrary OpenID providers
(which means that essentially no real authentication happens).

> Why not allow users to login with their own openid, but
> only allow one account to refer back to the same delegated account?

That sounds good. I'm not sure how to implement a provider change
in that scenario, though.

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

[Python-Dev] OpenID on PyPI: please discuss on ‘catalog-sig’ (was: Too many Python account s)

[Ben Finney]

Michael Foord  writes:

> myopenid *does* the validation, but my registered openid is
> www.voidspace.org.uk and I *should* be able to change provider without
> creating a new account.

I'm very glad this issue is being discussed, but it's unfortunately
taking place both here (where it's off-topic) and in private email
(where it's not as visible as it should be), which surely doesn't make
much sense.

I have started a new sub-thread over on ‘catalog-sig’ for this topic,
starting with Message-ID: <87zl6npiky.fsf...@benfinney.id.au>
http://mail.python.org/pipermail/catalog-sig/2009-November/002308.html>.
Please continue the discussion there; I'll be gathering together under
that thread some of the salient messages I've seen.

-- 
 \ “Anyone can do any amount of work provided it isn't the work he |
  `\  is supposed to be doing at the moment.” —Robert Benchley |
_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] Status of the Buildbot fleet and related bugs

[R. David Murray]

There are non-stable buildbots that are failing consistently, but this
message is about something else.  Now that the biggest stability
issues have been addressed some less-noisy stability issues are visible.
The two that I have noticed most often are test_httpsservers, which
hangs occasionally, and test_multiprocessing, which fails in various
assertions occasionally.

Since the buildbots are often slow and/or heavily loaded, I tried
increasing DELTA in test_multiprocessing, but while it did seem to help
some as evidenced by how how many times it ran in my buildbot using -F
before and after, it did not prevent failures.

--David (RDM)
___
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]

s...@pobox.com wrote:
> Martin> That's indeed what PyPI attempts to do. At the "claim openid"
> Martin> place, follow the Launchpad link. It should guide you through
> Martin> the procedure.
> 
> Well, since I use Google a lot more I'd prefer to use that.  If I click the
> Google OpenID link I now get
> 
> OpenID is already claimed

That means that you already did it. You can associate each OpenID only
with one account (and it doesn't special-case that you are trying to do
it again).

> Martin> Then, when you want to login, again follow the Launchpad link on
> Martin> the front page.
> 
> That seems to work, but I'm not sure how.

If it logs you in, it works.

> Doesn't seem to use cookies.  The
> Google OpenID link leads to
> 
> http://pypi.python.org/pypi?:action=login&provider=Google
> 
> which contains nothing about me.

Don't worry about that. That's how OpenID is supposed to work.

> I saw a pypi.python.org cookie which
> expires "On Quit", so I restarted Camino and verified there were no
> pypi.python.org cookies, then clicked the Google OpenID link.  It still
> works.  I must be missing something obvious...

It's far from obvious. It's called "provider-driven identifier
selection". PyPI redirects your browser to Google. Google looks at
the Google cookie, and finds your identity; they also see that you
have opted to automatically log into PyPI. So without further questions,
they redirect you back to PyPI. PyPI finds your account, and displays
a logged-in page.

Look Ma, no ugly login box with tons of characters to type.

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

[Michael Foord]

Martin v. Löwis wrote:

[snip...]

Why not allow users to login with their own openid, but
only allow one account to refer back to the same delegated account?



That sounds good. I'm not sure how to implement a provider change
in that scenario, though.

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


All the best,

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

[Martin v. Löwis]

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

For this to work, you would have to upgrade your web page to OpenID 2,
as this is the only protocol that PyPI supports.

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 (was Re: PyPI comments and ratings, *really*?)

[skip]

Martin> It's far from obvious. It's called "provider-driven identifier
Martin> selection". PyPI redirects your browser to Google. Google looks
Martin> at the Google cookie, and finds your identity; they also see
Martin> that you have opted to automatically log into PyPI. So without
Martin> further questions, they redirect you back to PyPI. PyPI finds
Martin> your account, and displays a logged-in page.

Thanks.  Makes sense now...

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

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

P.J. Eby wrote:
> 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.

I agree with Martin that anonymous votes, like anonymous comments, are
process-harmful here.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksA0aYACgkQ+gerLs4ltQ4WEACfUJmt5LEFujv5xZNCl1tbDGzR
CrIAoKUtK10tQVIiEbDljaHhyTssr4r5
=+UqM
-END 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] standard libraries don't behave like standard 'libraries'

[Kevin Teague]

On Nov 13, 2009, at 6:23 PM, Greg Ewing wrote:


Martin v. Löwis wrote:

> Some of the Python maintainers have recently started objecting to  
this
> setup, asking that the standard library should be split into  
separate
> packages that are released and distributed independent of Python.  
Others

> of us feel strongly that such a change should not be made.

I'd be worried, because I would no longer be able to
release an app or package and say "requires Python x.y".
I'd have to list the version numbers of all the micro
packages making up the standard library that I use.

Worse, I'd have to be aware of which ones I actually
*do* use so I could mantain that list, something I don't
have to think about at the moment.


"requires Python x.y" would imply a dependency on the working set of  
micro-packages which were shipped with that version of Python (or more  
specifically, any working set that was released within a particular  
Python release series). You would only need to list packages from the  
standard library as dependencies in special-case circumstances where  
you required a version higher or lower than what shipped with a  
particular release series of Python.


It would perhaps increase the potential for people to get into  
situations where they update a Python with newer packages which makes  
it incompatibe with other Python applications. This problem would be  
mitgated by the fact that the standard library tends to be very API  
stable, so usually newer releases only contain minor bug fixes or  
performance enhancements and are unlikely to cause breakage. Package  
installation tools would also still continue to install into site- 
packages, or ideally in a virtualenv or script-generation environement  
like Buildout does. So installing updates to the standard library  
could be done only to support those applications which require them,  
but leave the default working set untouched for any other Python  
applications. Conversely, it may also help the standard library  
compatability in some situations, as I've seen people copy newer files  
into the standard library locations as a method of applying bug fixes,  
and given a better set of metadata it would then be more natural to  
use tools which allowed updates to happen in an orderly fashion.


That's all given that splitting the standard library into individual  
packages also continues to release a single standard library. I don't  
really think releases small/medium/large sized standard libraries as  
was also discussed is a good idea.


Maybe usage of tools such as virtualenv and buildout aren't yet  
widespread enough to alleviate people mucking up their installations  
in such a way that causes them pain. And this would also make it  
easier for people to develop applications which would be harder to  
pakcage into linux distributions or other package managers which don't  
allow for non-global updates. However, these are only theoretical  
concerns. It's concrete issue such as this one:


http://stackoverflow.com/questions/1734373/including-package-data-with-distribute/

Where a developer uses something in the standard library, and a python- 
dev commiter provides a fix very quickly (yay Tarek!). But then that  
developer has to be told to wait a year until the next Python release,  
then wait until you've got the time to migrate the rest of your  
application to the new Python release, then you can finally use that  
fix, and in the meantime even though the issue has been solved you  
still need to workaround the problem! It's issues like this where it's  
hard not to want to avoid using standard library packages (beyond  
"core" modules which stable and only change very rarely lke os, sys,  
re, etc.) because there are unneccessary roadblocks between developer  
and user.


___
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

[Tres Seaver]

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


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksA1LEACgkQ+gerLs4ltQ5gCQCgtYpBewlnocHJf5hp33TfkLjG
72IAnRW1d9n2CO8S2V+9ewcMb81oWNL+
=GG45
-END 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] buildtime vs runtime in Distutils

[Nick Coghlan]

Tres Seaver wrote:
> Tarek Ziadé wrote:
>> 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.

I'm with Tres here - having distutils (aside from build_ext) depend on
non-Python parts of the source tree seem a little strange.

However, given that the recommended packaging includes the needed files,
putting an RFE on the tracker to reduce the runtime dependency on the
source code would be an acceptable response if there is something else
you'd rather be working on.

Cheers,
Nick.

___
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/ncoghlan%40gmail.com



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