Re: [Python-Dev] Python wiki

2010-09-26 Thread Martin v. Löwis 
>   1) Registering via OpenID is a bit clumsy since there is a "Register"
> link that does not mention OpenID.

Thanks. Fixed.

>   2) The URL registered with the OpenID provider is a bit of a wart:
> "http://pypi.python.org/pypi?:action=openid_return"; vs.
> "http://bitbucket.org/";

You mean, as this is what the provider then shows you for confirmation?

Unfortunately, this can't be changed anymore, or many of the existing
accounts break. When I started this, I was more unclear about the
relationship of "realm" and "return URL" (I'm still unclear, not
having used a realm yet).

>   3) The email I received asked me to "Complete your Cheese Shop
> registration" which I think is just an oversight since the relabeling to
> pypi.

Ok, fixed.

>   4) It's a bit clumsy that "Login" pops up an HTTP Authentication
> prompt, which is useless to someone who only has never set a password
> and relies only on an OpenID credential. Furthermore, the 401 page does
> not provide a quick way to get to use OpenID.

I think there is no way out wrt. to the basic auth prompt. I could
label the "Login" link "Password login" if you think this would help.
Preventing the browser from prompting the user on the chance they
might want to enter an OpenID is not possible, and stopping to use
basic authentication is not feasible.

> In general, I am pretty happy with pypi's support of OpenID considering
> it allowed me to use my own provider, which often has not been the case
> with other sites.

I guess you are then not in the class of users Guido was referring to,
but rather in the "ultra geeks" class. What regular user is actively
searching for an "OpenID provider"?

If you were using your facebook account (or some such) to log in
(i.e. a service that "the masses" likely use and which happens to
be an OpenID provider), I'd rather add another provider icon to
the front page.

> Although, I think it would be nice if I didn't have to go to another
> page to do that, but I may be biased by having such a short OpenID URI.

This is actually deliberate. I don't want to clutter the front page
with a wide entry field. And again, enjoying a short OpenID URI
probably does put you in the "ultra geek" category (which I
seriously don't mean as an offense).

I've learned that OpenID really is a mystery even to the fairly
technical usership of PyPI. As an anecdote, a user was puzzled that,
after registering the Google OpenID, all you need to do to login
is to click on the google logo, and that no user interaction
at all was required. This counters established expectations about
security so much to actually confuse long-term internet users.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.normcase rationale?

2010-09-26 Thread Paul Moore 
On 25 September 2010 23:57, Greg Ewing  wrote:
> Paul Moore wrote:
>
>> Windows has (I believe) user definable filesystems, too, but the OS
>> has "get me the real filename" style calls,
>
> Does it really, though? The suggestions I've seen for doing
> this involve abusing the short/long filename translation
> machinery, and I'm not sure they're guaranteed to return the
> actual case rather than something that happens to work.

There's another call available. I've been too lazy to go and look it
up, but I'll do so sometime today.
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

2010-09-26 Thread Nick Coghlan 
On Sat, Sep 25, 2010 at 9:20 AM, Tim Peters  wrote:
[MvL]
>> I think it would be possible to have two versions of
>> _PyGC_REFS_UNTRACKED, one being, say, -5.
>> _PyGC_REFS_UNTRACKED_AND_KEEP_IT_THAT_WAY would be what you get
>> when you call PyObject_GC_UnTrack; the code to do automatic
>> tracking/untracking based on contents would use some other
>> new API (which would be non-public in 2.7.x).
>
> Looks like a promising idea!  gcmodule.c's IS_TRACKED macro would have
> to change to check both states, and likewise the debug assert in
> visit_reachable().

Given the intent is to restore the 2.6 state, perhaps it is the
"UNTRACK_ALLOW_RETRACK" optimisation that should get the new special
value? Other than that, MvL's suggestion looks like a good idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] hg conversion: tags

2010-09-26 Thread Dirkjan Ochtman 
Hi all,

I've recently been working on the conversion more (since my thesis got
finished). I finally wrote the script that splits the release branches
from the feature branches, so that we can include the former in the
main repository and keep the latter in separate clones as needed.
Next, I wanted to look into tags. There's a big list of tags (see
below), and I wonder if I should clean that up or if we should leave
it as-is. For example, it might be interesting to bring old release
tags in line with newer tags (so Release_1_0 would become r10), or
maybe use clean tags similar to what we do with hg itself (r266 would
become just 2.6.6), or just remove some tags. Is this a good idea at
all, or should we just leave everything the way it is now?

Cheers,

Dirkjan

r32a2
r266
r266rc2
r266rc1
r32a1
r27
r27rc2
r27rc1
r27b2
r27b1
r312
r265
r265rc2
r312rc1
r27a4
r265rc1
r27a3
r255
r255c2
r255c1
r27a2
r27a1
r311
r264
r264rc2
r264rc1
r263
r263rc1
r311rc1
r31
r31rc2
r31rc1
r31b1
r262
r262c1
r31a2
r31a1
r301
r254
r253
r246
r253c1
r246c1
r261
r30
r30rc3
r30rc2
r26
r26rc2
r30rc1
r26rc1
r30b3
r26b3
r26b2
r30b2
r26b1
r30b1
r26a3
r30a5
r26a2
r30a4
r237
r245
r237c1
r245c1
r30a3
r26a1
r252
r252c1
r251c1
r30a2
r30a1
py3k-before-rstdocs
py26-before-rstdocs
r251
r236
r236c1
r244
r244c1
r25
r25c2
r25c1
r25b3
r25b2
r25b1
r25a2
r25a1
r25a0
r243
r25a0/trunk
r243c1
before-ast-merge-to-head
mrg_to_ast-branch_15OCT05
IDLE-syntax-root
r242
r242c1
email_Release_2_5_6
r241
r241c2
r241c1
r235
r235c1
merged_from_MAIN_07JAN05
mrg_to_ast-branch_05JAN05
pre-sf-818006
bsddb_version_4_3_0
release24-fork
r24
r24c1
r24b2
r24b1
r24a3
tim-doctest-closed
r24a2
tim-doctest-merge-24a2
r24a1
pre-sf-1149508
r234
email_Release_2_5_5
r234c1
start-sf-965425
before-ast-merge-from-head
bsddb_version_4_2_4
r233
r233c1
r232
r232c1
r231
pybsddb_after_bsddb42_01
pybsddb_before_bsddb42
r23-mac
r23
release23-fork
r23c2
r23rc1-fork
r23c1
bsddb_version_4_1_6
r23b2
r23b2-fork
anthony-parser-branchpoint
IDLELIB_CREATED
r09b1
r223
email_Release_2_5_3
r223c1
email_Release_2_5_2
r23b1-mac
r23b1
r23b1-fork
COPY_TO_PYTHON
mrg_to_ast-branch_24APR03
email_Release_2_5_1
cache-attr-fork
email_Release_2_5
r09a2nt
email_Release_2_5b1
r23a2
r23a2-fork
r09a2
LAST_OLD_IDLE
r09a1
r23a1
r23a1-fork
r09a0
before-bgen-pep252
r222-mac
r222
email_Release_2_4_3
email_Release_2_4_2
Distutils-1_0_3
r222b1
email_Release_2_4_1
email_Release_2_4
py-cvs-2002_09_13-merged
py-cvs-2002_09_13
MERGED_FROM_DS_RPC_13SEP02
MERGED_TO_MAIN_13SEP02
PRE_DS_RPC_MERGE
email_Release_2_3_1
email_Release_2_3
BEFORE_RESTART
email_Release_2_2
email_Release_2_1
final_classic_builds
email_Release_2_0_5
Release_2_0_4
TAG_pre_teyc_gvr_rpc_patch
r221
r213
r22p1
r221c2
r221c1
r1_95_2
r212
r212c1
release22-mac
release22-macmerge
release22
release22-fork
r22c1-mac
r22c1-macmergefromtrunk
r22c1
r22rc1-fork
final_CW6_projects
universal_headers_332
v0_10
r22b2-mac
r22b2
r22b2-fork
v0_09
r22b1-mac
v0_08
v0_07
v0_06
r22b1
r22b1-fork
r22b1-docs-prep
r22a4
r22a4-fork
r22a3
r22a3-fork
r22a3-docs-prep
r22a2
r22a2-docs-prep
r22a2-fork
before-carbon-package
after-descr-branch-merge
date2001-08-01
date2001-07-30
date2001-07-28
IDLEFORK_081_RELEASE
date2001-07-21
r211
r22a1
date2001-07-17b
date2001-07-17a
date2001-07-16
date2001-07-15
py-cvs-2001_07_13-merged
py-cvs-2001_07_13
py-cvs-rel2_1-merged
date2001-07-13
r211c1
py-cvs-rel2_1
py-cvs-2000_03_09
descr-fork
date2001-07-06
base-VP-idle
r201
r201c1
merged-with-main-repository
after-call-reorg
before-call-reorg
mac210
Distutils-1_0_2
release21
r21c2
r21c1
mac210b2
r21b2
mac210b1a
mac210b1
r21b1
mac210a3
r161
mac210a1
r21a2
r21a1
pre_amk
last_cw_pro_53
mac200
release20
Distutils-1_0_1
r20c1
Distutils-1_0
Distutils-0_9_4
r20b2
Distutils-0_9_3
r20b11
mac200b1
r20b1
release16
Distutils-0_9_2
last_68k_projects
cw_pro_5
Distutils-0_9_1
arelease
r16b1
r16b1-win
Distutils-0_9
Distutils-0_8_2
Distutils-0_8_1
Distutils-0_8
r16a2
Distutils-0_1_5
pre_GUSI2
Distutils-0_1_4
Distutils-0_1_3-branch
r16a1
release152p2
release152p1-branch-tag
pre-unicode
idle05
pre_0_2_breakage
Distutils-0_1_3
Distutils-0_1_2
Distutils-0_1_1
Distutils-0_1
mx_builder-alpha2
release152p1
pre-string-meths
Release_1_0
release152
r152
mac152c1
r152c1
r06
release152b2
r152b2
mac152b1
release152b1
idle-r02
r152b1
Release_0_1
r01
r152a2
Public_Release_20-Aug-1998
PYIDE_APR98
PYTHONSCRIPT_0_5b1
OSAM_APR98
BBPY_0_2_3
release152a1
r152a1
release151p1
mac151
r151
Public_Release_27-Mar-1998
Public_13-Mar-1998
Public_11-Mar-1998
release15
r15b2
r15b1
r15a4
r15a4near
r15a3
r15a2
r15a1
lastoldnames
lastoldname
release14
Python1_4final
r14beta3
Beta_20-Aug-1996
r14beta2
Beta_09-Aug-1996
Beta_05-Jul-1996
r14beta1
cwisync1
cnrisync2
chameleon-1
cnrisync
release13
r13beta1
Public_05-Jul-1995
release12
proof3
r12beta4
Python_1_2_release
Beta_20-Mar-1995
proof2
Beta_15-Mar-1995-#2
Beta_15-Mar-1995
Beta_14-Mar-1995-#3
Beta_14-Mar-1995-#2
Beta_14-Mar-1995
proof1
r12beta3
r12beta2
r12beta1
release111
release11
mhammond
mac102
release102
relea

Re: [Python-Dev] Relative imports in Py3k

2010-09-26 Thread Nick Coghlan 
On Sun, Sep 26, 2010 at 7:46 AM, "Martin v. Löwis"  wrote:
> What you read as a bug report was labeled "user story",
> which I think is anatoly's way of saying "it's not a bug
> report".

Skimming the original post, I actually thought of two possible
candidates that fit the "it doesn't work" moniker when it comes to
imports:

http://bugs.python.org/issue8098 (multi-threaded dodginess courtesy of
some deadlock avoidance we added a while back)
http://bugs.python.org/issue992389 (ah, the joys of circular imports -
our dear little 6 year old tracker issue...)

Not quite what anatoly is talking about though (see other post).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Relative imports in Py3k

2010-09-26 Thread Nick Coghlan 
On Sat, Sep 25, 2010 at 11:15 PM, anatoly techtonik  wrote:
> Hi,
>
> I wonder if situation with relative imports in packages is improved in
> Python 3k or
> we are still doomed to a chain of hacks?
>
> My user story:
> I am currently debugging project, which consists of many modules in one 
> package.
> Each module has tests or other useful stuff for debug in its main
> section, but it is a
> disaster to use it, because I can't just execute the module file and
> expect it to find
> relatives. All imports are like:
>
> from spyderlib.config import get_icon
> from spyderlib.utils.qthelpers import translate, add_actions, create_action

This is almost certainly failing because the directory containing the
spyderlib package isn't on sys.path anywhere (instead, whichever
directory contains the script you executed directly will be in there,
which will be somewhere inside the package instead of outside it). Put
the appropriate directory in PYTHONPATH and these tests should start
working.

> PEP 328 http://www.python.org/dev/peps/pep-0328/  proposes:
>
> from ... import config
> from ..utils.qthelpers import translate, add_actions, create_action

This fails for two reasons:
1. "__main__" is missing the module namespace information PEP 328
needs to do its thing
2. Even if 1 is resolved, PEP 328 will resolve to the same absolute
imports you're already using and likely fail for the same reason (i.e.
spyderlib not found on sys.path)

> But this doesn't work, and I couldn't find any short user level
> explanation why it is
> not possible to make this work at least in Py3k without additional magic.

If you use the -m switch to run your module from the directory that
contains the spyderlib package directory, it will work. The use of -m
provides the module namespace information that PEP 328 needs, while
running from the directory that contains the spyderlib package ensures
it is visible through sys.path.

The one caveat is that the specified module is run as "__main__" and
hence does not exist in sys.modules under its normal name. If it gets
imported by another module, then you will end up with two copies of
the module (one as "__main__" and one under the normal name). This may
or may not cause problems, depending on the nature of the module being
executed.

While PEP 366 describes the boilerplate you can put at the top of your
module to allow a directly executed module to try to find its
siblings, it still requires that PYTHONPATH be set appropriately. And
if you set PYTHONPATH appropriately, then direct execution with
absolute imports will work.

(The explanation of the failures applies for all Python versions that
I am aware of, but the -m based fix only became available in 2.6)
(The impact of various command line options and the PYTHONPATH
environment variable on sys.path are described at
http://docs.python.org/using/cmdline.html)
(The basic import search algorithm is described in the tutorial:
http://docs.python.org/tutorial/modules.html#the-module-search-path)
(And the full gory specification details are in PEP 302, with a few
subsequent tweaks courtesy of PEP 328 and PEP 366).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.normcase rationale?

2010-09-26 Thread Paul Moore 
On 26 September 2010 09:01, Paul Moore  wrote:
> On 25 September 2010 23:57, Greg Ewing  wrote:
>> Paul Moore wrote:
>>
>>> Windows has (I believe) user definable filesystems, too, but the OS
>>> has "get me the real filename" style calls,
>>
>> Does it really, though? The suggestions I've seen for doing
>> this involve abusing the short/long filename translation
>> machinery, and I'm not sure they're guaranteed to return the
>> actual case rather than something that happens to work.
>
> There's another call available. I've been too lazy to go and look it
> up, but I'll do so sometime today.

Hmm, I can't find the one I was thinking of. GetLongFileName correctly
sets the case of all but the final part, and FindFile can be used to
find the last part, but that's not what I recall.

GetFinalPathNameByHandle works, and is documented to do so, but (a) it
works on an open file handle, so you need to open the file, and (b)
it's Vista and later only...

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

2010-09-26 Thread Martin v. Löwis 
> For example, it might be interesting to bring old release
> tags in line with newer tags (so Release_1_0 would become r10), or
> maybe use clean tags similar to what we do with hg itself (r266 would
> become just 2.6.6), or just remove some tags. Is this a good idea at
> all, or should we just leave everything the way it is now?

Removing tags sounds fine with me. Renaming them not so; I fail to see
the point.

> before-ast-merge-to-head
> mrg_to_ast-branch_15OCT05

These could go, IMO. Anything that's there for merge maintenance can
go, IMO.

> IDLE-syntax-root

This one can go as well. In general, I propose to remove all tags which
aren't copies of trunk or some branch (i.e. tagging only a part of the
Python source tree). I suppose hg can't represent that adequately,
anyway (they often come from CVS, and even CVS can only barely represent
tags that cover only one or a few files).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-26 Thread Nick Coghlan 
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou  wrote:
>
>> > But how should a performance improvement be filed? Bug? Feature request?
>> > Or should "feature request" be renamed "improvement"?
>>
>> It's a feature request (since we won't backport it unless there is a
>> genuine performance problem being addressed as a bug fix). Whether
>> that warrants changing the name, I don't know.
>
> I think most people won't intuitively file performance issues as
> "feature requests", since it doesn't sound like a feature.

Agreed.

>>  A third option for
>> "other improvement" may also work (since that would also cover things
>> like clarifying doc wording, fixing comments, adjusting code to be
>> more readable/obviously correct, etc).
>
> But then why not keep a clear categorization of these "other
> improvements"?

Because it's asking people to make a decision too early in the
process. The clear categorisation as to what *kind* of
bug/feature/improvement it is can be supplied later on by selecting
the appropriate components and keywords.

> By the way, doc wording fixes and cosmetic code changes often get
> backported. :)

Yep, hence why I think the basic "bug, feature, other" split may be a
good way to go. It's a quick and easy decision most of the time
(including a clear choice for "I don't know if this is a bug or not"),
and makes a meaningful procedural distinction (bugs are usually
backported, new features are not, and other changes may be backported
depending on the details).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

2010-09-26 Thread Dirkjan Ochtman 
On Sun, Sep 26, 2010 at 13:40, "Martin v. Löwis"  wrote:
> This one can go as well. In general, I propose to remove all tags which
> aren't copies of trunk or some branch (i.e. tagging only a part of the
> Python source tree). I suppose hg can't represent that adequately,
> anyway (they often come from CVS, and even CVS can only barely represent
> tags that cover only one or a few files).

Ah, yeah, that would definitely be a good reason to remove some of these.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Nick Coghlan 
On Sun, Sep 26, 2010 at 8:16 AM, "Martin v. Löwis"  wrote:
> But that can't work: then off-site links into either wiki break.

Georg isn't suggesting a general structural change, just a change to
have the URL when you land *directly* on wiki.python.org automatically
rewritten to resolve to wiki.python.org/moin. Any URL with additional
path info would be handled the same as it is now.

I've certainly run into this, since Firefox will turn "wiki.p" into
wiki.python.org for me and it (mildly) irritates me every time that
that doesn't actually take me to the front page of the wiki.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Nick Coghlan 
On Sat, Sep 25, 2010 at 6:20 PM, anatoly techtonik  wrote:
> My advice - subscribe people editing page by default (a checkbox near
> submit button). This way more people will receive notifications when a
> page is changed and will be more interested to contribute themselves.
> Of course, there must be a setting to opt out.

My experience with the auto-nosy setting on Roundup actually makes me
quite positive towards this idea. It's especially useful when coupled
with the query for "Issues followed by me" and the new "add me to the
nosy list" button.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.normcase rationale?

2010-09-26 Thread Dirkjan Ochtman 
On Sun, Sep 26, 2010 at 13:36, Paul Moore  wrote:
> Hmm, I can't find the one I was thinking of. GetLongFileName correctly
> sets the case of all but the final part, and FindFile can be used to
> find the last part, but that's not what I recall.
>
> GetFinalPathNameByHandle works, and is documented to do so, but (a) it
> works on an open file handle, so you need to open the file, and (b)
> it's Vista and later only...

FWIW, here's what Mercurial uses to get the real path name on Windows:

http://hg.intevation.org/mercurial/crew/file/66a07fb76ceb/mercurial/util.py#l633

(I don't know much about that code or this topic, but maybe someone
finds it useful. It doesn't use any "special" Windows API, so if there
is any, it's something the hg hackers don't know about.)

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.normcase rationale?

2010-09-26 Thread James Y Knight 

On Sep 26, 2010, at 7:36 AM, Paul Moore wrote:

> On 26 September 2010 09:01, Paul Moore  wrote:
>> On 25 September 2010 23:57, Greg Ewing  wrote:
>>> Paul Moore wrote:
>>> 
 Windows has (I believe) user definable filesystems, too, but the OS
 has "get me the real filename" style calls,
>>> 
>>> Does it really, though? The suggestions I've seen for doing
>>> this involve abusing the short/long filename translation
>>> machinery, and I'm not sure they're guaranteed to return the
>>> actual case rather than something that happens to work.
>> 
>> There's another call available. I've been too lazy to go and look it
>> up, but I'll do so sometime today.
> 
> Hmm, I can't find the one I was thinking of. GetLongFileName correctly
> sets the case of all but the final part, and FindFile can be used to
> find the last part, but that's not what I recall.
> 
> GetFinalPathNameByHandle works, and is documented to do so, but (a) it
> works on an open file handle, so you need to open the file, and (b)
> it's Vista and later only...

Were you thinking of SHGetFileInfo?

http://stackoverflow.com/questions/74451/getting-actual-file-name-with-proper-casing-on-windows

James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Martin v. Löwis 
Am 26.09.2010 13:58, schrieb Nick Coghlan:
> On Sun, Sep 26, 2010 at 8:16 AM, "Martin v. Löwis"  wrote:
>> But that can't work: then off-site links into either wiki break.
> 
> Georg isn't suggesting a general structural change, just a change to
> have the URL when you land *directly* on wiki.python.org automatically
> rewritten to resolve to wiki.python.org/moin.

I suppose you mean "to redirect to"? I think there would be problems if
wiki.python.org actually returned the same content as wiki.python.org/moin.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.normcase rationale?

2010-09-26 Thread Paul Moore 
On 26 September 2010 13:37, James Y Knight  wrote:
>
> Were you thinking of SHGetFileInfo?
>
> http://stackoverflow.com/questions/74451/getting-actual-file-name-with-proper-casing-on-windows

It wasn't, but it looks possible. Only gives the last component,
though, so you still have to walk up the path components :-(

I suspect I was thinking of GetLongFileName, which puts everything
*but* the last component into the right case. I missed the problem
with the last component :-(

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Nick Coghlan 
On Sun, Sep 26, 2010 at 10:59 PM, "Martin v. Löwis"  wrote:
> Am 26.09.2010 13:58, schrieb Nick Coghlan:
>> On Sun, Sep 26, 2010 at 8:16 AM, "Martin v. Löwis"  
>> wrote:
>>> But that can't work: then off-site links into either wiki break.
>>
>> Georg isn't suggesting a general structural change, just a change to
>> have the URL when you land *directly* on wiki.python.org automatically
>> rewritten to resolve to wiki.python.org/moin.
>
> I suppose you mean "to redirect to"? I think there would be problems if
> wiki.python.org actually returned the same content as wiki.python.org/moin.

I don't actually have any specific preference as to implementation
details, aside from it being something that works without breaking the
rest of the web server :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread P.J. Eby 

At 07:15 PM 9/25/2010 -0700, Guido van Rossum wrote:

Don't see this as a new spec. See it as a procedural issue.


As a procedural issue, PEP 333 is an Informational PEP, in "Draft" 
status, which I'd like to make Final after these amendments.  See 
http://www.wsgi.org/wsgi/Amendments_1.0, which Graham created in 2007, stating:


"""This page is intended to collect any ideas related to amendments 
to the original WSGI 1.0 so that it can be marked as 'Final'."""


IOW, there is no intention to treat the PEP as "mutable" going 
forward; this is just cleanup so we can mark it Final.  After that, 
it's an ex-parrot.




Clarifications of ambiguous/unspecified behavior can possibly rule as
non-conforming implementations that used to get the benefit of the
doubt. Best-practice recommendations also have the effect of changing
(perceived) compliance.


I understand the general principle, but with respect to these 
*specific* changes, any perceived-compliance arguments that were 
going to happen, already happened years ago.  The changes are merely 
to officially document the way those arguments already turned out, so 
the PEP can become Final.


Specifically, the changes all fall into one of three categories:

1. Textual clarification (SERVER_PORT is not an int, iteration can 
stop before all output is consumed)


2. Practical issues with wsgi.input arising from the fact that 
real-world programs needed its behavior to be more "file-like" than 
the specification required...  and which essentially forced servers 
that were not using socket.makefile() to make their emulations work 
like that, anyway (or else be rejected by users).


3. Clarification of behavior that would break HTTP compliance (apps 
or servers sending more than Content-Length bytes) and is therefore 
*already a bug* in any implementation that does it.


Since in all three categories any implementation that did not end up 
following the recommendations on its own is going to have been 
considered buggy by its users (regardless of its formal 
"compliance"), and because the changes do not actually declare the 
buggy behaviors in categories 2 and 3 to be non-compliant, I do not 
see how any of these changes can produce the type of problems you're 
worried about here.


Certainly, if I thought such problems were possible, I wouldn't have 
accepted these amendments.  Likewise, if I thought that changes would 
continue to be made to the PEP past this point, the goal wouldn't be 
getting it to Final status.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Georg Brandl 
Am 26.09.2010 14:59, schrieb "Martin v. Löwis":
> Am 26.09.2010 13:58, schrieb Nick Coghlan:
>> On Sun, Sep 26, 2010 at 8:16 AM, "Martin v. Löwis"  
>> wrote:
>>> But that can't work: then off-site links into either wiki break.
>> 
>> Georg isn't suggesting a general structural change, just a change to
>> have the URL when you land *directly* on wiki.python.org automatically
>> rewritten to resolve to wiki.python.org/moin.
> 
> I suppose you mean "to redirect to"? I think there would be problems if
> wiki.python.org actually returned the same content as wiki.python.org/moin.

I've been talking about redirecting all the time, haven't I?  Plan is simple:

* redirect from wiki.python.org to wiki.python.org/moin

* (optionally) redirect from wiki.jython.org to wiki.python.org/jython
  -- or --
  make wiki.jython.org the canonical URI for the Jython wiki and redirect
  from old /jython URIs there.

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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Martin v. Löwis 
> I've been talking about redirecting all the time, haven't I?

You said "put the Jython wiki somewhere on its own". That seemed to
suggest it won't be anymore at wiki.python.org/jython.

> * redirect from wiki.python.org to wiki.python.org/moin
> 
> * (optionally) redirect from wiki.jython.org to wiki.python.org/jython
>   -- or --
>   make wiki.jython.org the canonical URI for the Jython wiki and redirect
>   from old /jython URIs there.

I've asked Frank Wierzbicki which one he prefers.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

2010-09-26 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/26/2010 07:40 AM, "Martin v. Löwis" wrote:
>> For example, it might be interesting to bring old release
>> tags in line with newer tags (so Release_1_0 would become r10), or
>> maybe use clean tags similar to what we do with hg itself (r266 would
>> become just 2.6.6), or just remove some tags. Is this a good idea at
>> all, or should we just leave everything the way it is now?
> 
> Removing tags sounds fine with me. Renaming them not so; I fail to see
> the point.

One point is to remove inconsistencies tied to CVS-era restrictions:
the tags which correspond to (define) actual numbered releases have
goofy names due to CVSism ('r266' is a ridiculously hard-to-figure-out
alternative to '2.6.6').

Given that nobody will be able to update checkouts in place anyway, I
think taking this opportunity to use "real" version IDs for tags would
be a much better than sticking with the old cruft.



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

iEYEARECAAYFAkyfXj4ACgkQ+gerLs4ltQ6fZQCeJIQzz4CO9D/Jc1ryeO9zhiUA
/EcAn3IkPDOpJetd9kC6/gqpNqN8JHkC
=0roB
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/26/2010 02:31 AM, "Martin v. Löwis" wrote:
> Am 26.09.2010 03:45, schrieb P.J. Eby:
>> I'm actually a bit surprised people are bringing this up now, since when
>> I announced the plan to make these changes, I said that nothing would be
>> changed that would break anything
> 
> I think people read this as "nothing would be changed, period."
> 
> However, you did make substantial changes to the specification (or else
> the whole exercise would have been pointless, I suppose, and you
> couldn't have claimed that WSGI is now Python 3-friendly when it
> previously was not).

The clarifications remove Python3-only ambiguities, making it possible
for to implement both sides the spec sanely and consistently under Python 3.

> So this is essentially a new version of the spec. As PEPs themselves
> are not versioned (unlike, say, ISO standards), Guido insists it ought
> to get a new PEP number. Then, people declaring compliance can identify
> what specification they actually comply to. Declaring compliance to
> PEP 333 as-of-last-week-but-not-as-of-today is now difficult. This
> particularly puzzles people some of the existing WSGI servers are
> now incompatible to the PEP, when they still were compatible last
> week.

PJE's claim is that there are *no* such servers:

> So, no (previously-)compliant implementations were harmed in the 
> making of the updated spec.  If they were compliant before, they're 
> compliant now.

I hadn't realized that PEP 333 was never actually in the 'Final' status
(de facto, it has been so for years, of course).  Given that fact, and
PJEs assurances, I think amending the PEP and then immediately declaring
it final is reasonable.


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

iEYEARECAAYFAkyfX6MACgkQ+gerLs4ltQ7tjgCfXP4SamlyjLenSsHib0O8E03d
MbEAnR+lsNoUb7PH4NkdKNL1rToWXTsi
=s5d7
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread Guido van Rossum 
On Sun, Sep 26, 2010 at 7:58 AM, Tres Seaver  wrote:
> I hadn't realized that PEP 333 was never actually in the 'Final' status
> (de facto, it has been so for years, of course).  Given that fact, and
> PJEs assurances, I think amending the PEP and then immediately declaring
> it final is reasonable.

And who is going to give the PEP its stamp of approval?

I'm sorry, but all this weasel-wording about how these changes aren't
really changes and how this standard wasn't really a standard make me
very uncomfortable. I'm happy approving Final status for the
*original* PEP 333 and I'm happy to approve a new PEP which includes
PJE's corrections. I'm not going to approve Final status for a
history-rewrite of PEP 333.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.path.normcase rationale?

2010-09-26 Thread Brian Curtin 
On Sun, Sep 26, 2010 at 06:36, Paul Moore  wrote:

> On 26 September 2010 09:01, Paul Moore  wrote:
> > On 25 September 2010 23:57, Greg Ewing 
> wrote:
> >> Paul Moore wrote:
> >>
> >>> Windows has (I believe) user definable filesystems, too, but the OS
> >>> has "get me the real filename" style calls,
> >>
> >> Does it really, though? The suggestions I've seen for doing
> >> this involve abusing the short/long filename translation
> >> machinery, and I'm not sure they're guaranteed to return the
> >> actual case rather than something that happens to work.
> >
> > There's another call available. I've been too lazy to go and look it
> > up, but I'll do so sometime today.
>
> GetFinalPathNameByHandle works, and is documented to do so, but (a) it
> works on an open file handle, so you need to open the file, and (b)
> it's Vista and later only...


FYI, this is currently exposed as nt._getfinalpathname, and is used for
os.path.samefile on Vista and beyond.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread Martin v. Löwis 
>> I think people read this as "nothing would be changed, period."
> 
>> However, you did make substantial changes to the specification (or else
>> the whole exercise would have been pointless, I suppose, and you
>> couldn't have claimed that WSGI is now Python 3-friendly when it
>> previously was not).
> 
> The clarifications remove Python3-only ambiguities, making it possible
> for to implement both sides the spec sanely and consistently under Python 3.

Sure. I don't argue whether this is an improvement.

I claim that it is a specification change, long after the specification
has been implemented multiple times. It thus deserves to get a new
name (i.e. PEP number).

PJE says that strictly speaking, the PEP had not been accepted yet.
However, at this stage, claiming that it is still open for edits
is really confusing, IMO.

>> So this is essentially a new version of the spec. As PEPs themselves
>> are not versioned (unlike, say, ISO standards), Guido insists it ought
>> to get a new PEP number. Then, people declaring compliance can identify
>> what specification they actually comply to. Declaring compliance to
>> PEP 333 as-of-last-week-but-not-as-of-today is now difficult. This
>> particularly puzzles people some of the existing WSGI servers are
>> now incompatible to the PEP, when they still were compatible last
>> week.
> 
> PJE's claim is that there are *no* such servers:

Does that claim include wsgiref?

> I hadn't realized that PEP 333 was never actually in the 'Final' status
> (de facto, it has been so for years, of course).  Given that fact, and
> PJEs assurances, I think amending the PEP and then immediately declaring
> it final is reasonable.

I'm still with Guido here: I'd accept PEP 333 as final in the state it
had last week, give PJE's edits a new PEP number, and accept that as
final right away also.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread Martin v. Löwis 
> I'm sorry, but all this weasel-wording about how these changes aren't
> really changes and how this standard wasn't really a standard make me
> very uncomfortable. I'm happy approving Final status for the
> *original* PEP 333 and I'm happy to approve a new PEP which includes
> PJE's corrections. I'm not going to approve Final status for a
> history-rewrite of PEP 333.

+1

Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

2010-09-26 Thread Martin v. Löwis 
> One point is to remove inconsistencies tied to CVS-era restrictions:
> the tags which correspond to (define) actual numbered releases have
> goofy names due to CVSism ('r266' is a ridiculously hard-to-figure-out
> alternative to '2.6.6').
> 
> Given that nobody will be able to update checkouts in place anyway, I
> think taking this opportunity to use "real" version IDs for tags would
> be a much better than sticking with the old cruft.

Please understand that this will also delay the introduction of
Mercurial. Not only will the tag names have to be changed, but also all
software doing automatic processing of tag names will have to be updated
(in addition to being ported to Mercurial, which is necessary either
way).

But then, if somebody volunteers to make these changes, I'm -0 to
the renaming (I slightly prefer calling even future release tags rXYZ).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyObject_GC_UnTrack() no longer reliable in 2.7?

2010-09-26 Thread Martin v. Löwis 
Am 26.09.2010 12:54, schrieb Nick Coghlan:
> On Sat, Sep 25, 2010 at 9:20 AM, Tim Peters  wrote:
> [MvL]
>>> I think it would be possible to have two versions of
>>> _PyGC_REFS_UNTRACKED, one being, say, -5.
>>> _PyGC_REFS_UNTRACKED_AND_KEEP_IT_THAT_WAY would be what you get
>>> when you call PyObject_GC_UnTrack; the code to do automatic
>>> tracking/untracking based on contents would use some other
>>> new API (which would be non-public in 2.7.x).
>>
>> Looks like a promising idea!  gcmodule.c's IS_TRACKED macro would have
>> to change to check both states, and likewise the debug assert in
>> visit_reachable().
> 
> Given the intent is to restore the 2.6 state, perhaps it is the
> "UNTRACK_ALLOW_RETRACK" optimisation that should get the new special
> value? Other than that, MvL's suggestion looks like a good idea.

It would work either way, of course.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread P.J. Eby 

At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:

I'm happy approving Final status for the
*original* PEP 333 and I'm happy to approve a new PEP which includes
PJE's corrections.


Can we make it PEP , then?  ;-)

That number would at least communicate that it's the same thing, but 
for Python 3.


Really, my reason for trying to do the (non Py3-specific) amendments 
in a way that didn't require a new PEP number was because of the many 
ancillary questions that it raises for the community, such as:


* Is this is some sort of competition/replacement to PEP 444?
* What happened to the old one, why can't we just use that?
* Why isn't there a different protocol version?
* How is this different from the old one?

To be fair, I *also* wanted to avoid all the work associated with 
*answering* them.  ;-)  (Heck, I really wanted to avoid the work of 
having to even *think* about which questions *might* arise and how 
they'd need to be addressed.)


OTOH, I can certainly see that my attempt to avoid this has *already* 
failed: it simply brought up a different set of questions, just on 
Python-Dev instead of Web-SIG or Python-list.


Oh well.  Perhaps making the numbering appear to be a continuation 
will help a bit.


Another option would be to make a PEP that consists solely of the 
amendments and errata themselves, as this would answer most of the 
above questions directly.


Still another would be to abandon the effort to amend the PEP, and 
simply leave things as they are now: AFAICT, the fact that these 
amendments aren't in the PEP hasn't stopped anybody from *treating* 
most of them as if they were.  (Because everyone understands that 
failure to follow them constitutes a bug in your program, even if it 
technically complies with the spec.)



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread Vinay Sajip 
Martin v. Löwis  v.loewis.de> writes:

> 
> I'm still with Guido here: I'd accept PEP 333 as final in the state it
> had last week, give PJE's edits a new PEP number, and accept that as
> final right away also.
> 

This sounds like it should make everyone happy - no rewriting of history, and no
procedural roadblocks or delays to the amendments PJE wants to make. Are we done
here, or am I missing something?



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

2010-09-26 Thread Terry Reedy 

On 9/26/2010 7:43 AM, Nick Coghlan wrote:


Yep, hence why I think the basic "bug, feature, other" split may be a
good way to go. It's a quick and easy decision most of the time
(including a clear choice for "I don't know if this is a bug or not"),
and makes a meaningful procedural distinction (bugs are usually
backported, new features are not, and other changes may be backported
depending on the details).


+1 on 3 categories. The categories other than the main two are used so 
seldom as to make the differentiation pretty useless.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

2010-09-26 Thread Terry Reedy 

On 9/26/2010 12:54 PM, "Martin v. Löwis" wrote:


But then, if somebody volunteers to make these changes, I'm -0 to
the renaming (I slightly prefer calling even future release tags rXYZ).


Except that r311 could be either 3.1.1 or 3.11 (should be ever get that 
far ;-).

--
Terry Jan Reedy


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Steve Holden 
On 9/26/2010 10:25 AM, "Martin v. Löwis" wrote:
>> I've been talking about redirecting all the time, haven't I?
> 
> You said "put the Jython wiki somewhere on its own". That seemed to
> suggest it won't be anymore at wiki.python.org/jython.
> 
>> * redirect from wiki.python.org to wiki.python.org/moin
>>
>> * (optionally) redirect from wiki.jython.org to wiki.python.org/jython
>>   -- or --
>>   make wiki.jython.org the canonical URI for the Jython wiki and redirect
>>   from old /jython URIs there.
> 
> I've asked Frank Wierzbicki which one he prefers.
> 
Strikes me this is a much needed change.  Thanks!

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Terry Reedy 

On 9/26/2010 1:33 PM, P.J. Eby wrote:

Thank you do doing the needed rewrite.


Can we make it PEP , then? ;-)

That number would at least communicate that it's the same thing, but for
Python 3.


A new rewriten PEP gives you a bit more freedom than doing it in place. 
It will be easier to refer to the existing PEP 333 rather than "an 
earlier version of this PEP".




Really, my reason for trying to do the (non Py3-specific) amendments in
a way that didn't require a new PEP number was because of the many
ancillary questions that it raises for the community, such as:

* Is this is some sort of competition/replacement to PEP 444?
* What happened to the old one, why can't we just use that?
* Why isn't there a different protocol version?


You can also (briefly) answer questions like these in a new section.
I would refer people to the web-sig if they have further questions.


* How is this different from the old one?


You could mark added material is a way that does not conflict with rst 
or html. Or use .rst to make new text stand out in the .html web verion 
(bold, underlined, red, or whatever). People familiar with 333 can focus 
on the marked sections. New readers can ignore the marking.



To be fair, I *also* wanted to avoid all the work associated with
*answering* them. ;-) (Heck, I really wanted to avoid the work of having
to even *think* about which questions *might* arise and how they'd need
to be addressed.)

OTOH, I can certainly see that my attempt to avoid this has *already*
failed: it simply brought up a different set of questions, just on
Python-Dev instead of Web-SIG or Python-list.


You can't win in situations like this.


Oh well. Perhaps making the numbering appear to be a continuation will
help a bit.

Another option would be to make a PEP that consists solely of the
amendments and errata themselves, as this would answer most of the above
questions directly.


Please no. Terrible to read. Mark important changes, as suggested above, 
in a complete text.


Still another would be to abandon the effort to amend the PEP, and
simply leave things as they are now: AFAICT, the fact that these
amendments aren't in the PEP hasn't stopped anybody from *treating* most
of them as if they were. (Because everyone understands that failure to
follow them constitutes a bug in your program, even if it technically
complies with the spec.)


Please no ;-).

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

2010-09-26 Thread Martin v. Löwis 
Am 26.09.2010 20:31, schrieb Terry Reedy:
> On 9/26/2010 12:54 PM, "Martin v. Löwis" wrote:
> 
>> But then, if somebody volunteers to make these changes, I'm -0 to
>> the renaming (I slightly prefer calling even future release tags rXYZ).
> 
> Except that r311 could be either 3.1.1 or 3.11 (should be ever get that
> far ;-).

And indeed, we cannot possibly go that far. Guido has Pronounced long
ago that version numbers can go only from 0 to 9.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] WSGI is now Python 3-friendly

2010-09-26 Thread Paul Moore 
On 26 September 2010 19:01, Vinay Sajip  wrote:
> Martin v. Löwis  v.loewis.de> writes:
>
>>
>> I'm still with Guido here: I'd accept PEP 333 as final in the state it
>> had last week, give PJE's edits a new PEP number, and accept that as
>> final right away also.
>>
>
> This sounds like it should make everyone happy - no rewriting of history, and 
> no
> procedural roadblocks or delays to the amendments PJE wants to make. Are we 
> done
> here, or am I missing something?

Sounds fine to me (PJE's response to Guido seems to imply he might
still have an issue, but I really hope not - let's get the new version
finalised and move on).

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Barry Warsaw 
On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:

> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
>> I'm happy approving Final status for the
>> *original* PEP 333 and I'm happy to approve a new PEP which includes
>> PJE's corrections.
> 
> Can we make it PEP , then?  ;-)

That works for me.
-Barry

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Guido van Rossum 
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw  wrote:
> On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
>
>> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
>>> I'm happy approving Final status for the
>>> *original* PEP 333 and I'm happy to approve a new PEP which includes
>>> PJE's corrections.
>>
>> Can we make it PEP , then?  ;-)
>
> That works for me.

Go for it.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread P.J. Eby 

At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:

On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw  wrote:
> On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
>
>> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
>>> I'm happy approving Final status for the
>>> *original* PEP 333 and I'm happy to approve a new PEP which includes
>>> PJE's corrections.
>>
>> Can we make it PEP , then?  ;-)
>
> That works for me.

Go for it.


Shall I just "svn cp" it, then (to preserve edit history), or wait 
for the PEP editor do it?


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Guido van Rossum 
Since you have commit privileges, just do it. The PEP editor position
mostly exists to assure non-committers are not prevented from
authoring PEPs.

Please do add a prominent note at the top of PEP 333 pointing to PEP
 for further information on Python 3 compliance or some such
words. Add a similar note at the top of PEP  -- maybe mark up the
differences in PEP  so people can easily tell what was added. And
move PEP 333 to Final status.

--Guido

On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby  wrote:
> At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
>>
>> On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw  wrote:
>> > On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
>> >
>> >> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
>> >>> I'm happy approving Final status for the
>> >>> *original* PEP 333 and I'm happy to approve a new PEP which includes
>> >>> PJE's corrections.
>> >>
>> >> Can we make it PEP , then?  ;-)
>> >
>> > That works for me.
>>
>> Go for it.
>
> Shall I just "svn cp" it, then (to preserve edit history), or wait for the
> PEP editor do it?
>
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Nick Coghlan 
On Mon, Sep 27, 2010 at 6:56 AM, Guido van Rossum  wrote:
> Since you have commit privileges, just do it. The PEP editor position
> mostly exists to assure non-committers are not prevented from
> authoring PEPs.
>
> Please do add a prominent note at the top of PEP 333 pointing to PEP
>  for further information on Python 3 compliance or some such
> words. Add a similar note at the top of PEP  -- maybe mark up the
> differences in PEP  so people can easily tell what was added. And
> move PEP 333 to Final status.

Since PEP 333 is referred to as both by both its PEP number and as
WSGI 1.0, should the new PEP explicitly state that PEP  is WSGI
1.0.1? (i.e. not a full update, even to 1.1 status, just some small
tweaks to make it usable in the Python 3 world along with some
generally applicable clarifications).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread P.J. Eby 
Done.  The other amendments were never actually made, so I just 
reverted the Python 3 bit after moving it to the new PEP.  I'll make 
the changes to  instead as soon as I have another time slot free.


At 01:56 PM 9/26/2010 -0700, Guido van Rossum wrote:

Since you have commit privileges, just do it. The PEP editor position
mostly exists to assure non-committers are not prevented from
authoring PEPs.

Please do add a prominent note at the top of PEP 333 pointing to PEP
 for further information on Python 3 compliance or some such
words. Add a similar note at the top of PEP  -- maybe mark up the
differences in PEP  so people can easily tell what was added. And
move PEP 333 to Final status.

--Guido

On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby  wrote:
> At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
>>
>> On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw  wrote:
>> > On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
>> >
>> >> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
>> >>> I'm happy approving Final status for the
>> >>> *original* PEP 333 and I'm happy to approve a new PEP which includes
>> >>> PJE's corrections.
>> >>
>> >> Can we make it PEP , then?  ;-)
>> >
>> > That works for me.
>>
>> Go for it.
>
> Shall I just "svn cp" it, then (to preserve edit history), or wait for the
> PEP editor do it?
>
>



--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread P.J. Eby 

At 02:59 PM 9/26/2010 -0400, Terry Reedy wrote:
You could mark added material is a way that does not conflict with 
rst or html. Or use .rst to make new text stand out in the .html web 
verion (bold, underlined, red, or whatever). People familiar with 
333 can focus on the marked sections. New readers can ignore the marking.


If you (or anybody else) have any idea how to do that (highlight 
stuff in PEP-dialect .rst), let me know.


(For that matter, if anybody knows how to make it not turn *every* 
PEP reference into a link, that'd be good too!  It doesn't really 
need to turn 5 or 6 occurrences of "PEP 333" in the same paragraph 
into separate links.  ;-) )


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Ben Finney 
"P.J. Eby"  writes:

> (For that matter, if anybody knows how to make it not turn *every* PEP
> reference into a link, that'd be good too! It doesn't really need to
> turn 5 or 6 occurrences of "PEP 333" in the same paragraph into
> separate links. ;-) )

reST, being designed explicitly for Python documentation, has support
for PEP references built in:

The :pep-reference: role is used to create an HTTP reference to a
PEP (Python Enhancement Proposal). The :PEP: alias is usually used.
For example:

See :PEP:`287` for more information about reStructuredText.

This is equivalent to:

See `PEP 287`__ for more information about reStructuredText.

__ http://www.python.org/peps/pep-0287.html

http://docutils.sourceforge.net/docs/ref/rst/roles.html#pep-reference>.

-- 
 \ “What is needed is not the will to believe but the will to find |
  `\  out, which is the exact opposite.” —Bertrand Russell |
_o__)  |
Ben Finney

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread P.J. Eby 

At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:

"P.J. Eby" <pje 
at telecommunity.com> writes:


> (For that matter, if anybody knows how to make it not turn *every* PEP
> reference into a link, that'd be good too! It doesn't really need to
> turn 5 or 6 occurrences of "PEP 333" in the same paragraph into
> separate links. ;-) )

reST, being designed explicitly for Python documentation, has support
for PEP references built in:



You misunderstand me; I wasn't asking how to *add* a link, but how to 
turn OFF the automatic conversion of the phrase "PEP 333" that 
happens without any special markup.


Currently, the PEP  preface is littered with unnecessary links, 
because the PEP pre-processor turns *every* mere textual mention of a 
PEP into a link to it.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly

2010-09-26 Thread Ben Finney 
"P.J. Eby"  writes:

> At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
>
> >reST, being designed explicitly for Python documentation, has support
> >for PEP references built in:
>
> You misunderstand me; I wasn't asking how to *add* a link, but how to
> turn OFF the automatic conversion of the phrase "PEP 333" that happens
> without any special markup.
[…]

Right, I misread. Sorry for the noise.

-- 
 \“Beware of bugs in the above code; I have only proved it |
  `\ correct, not tried it.” —Donald Knuth, 1977-03-29 |
_o__)  |
Ben Finney

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Scott Dial 
On 9/26/2010 3:12 AM, Martin v. Löwis wrote:
>>   2) The URL registered with the OpenID provider is a bit of a wart:
>> "http://pypi.python.org/pypi?:action=openid_return"; vs.
>> "http://bitbucket.org/";
> 
> You mean, as this is what the provider then shows you for confirmation?

The provider also lists the trusted sites by these return URLs, and that
is where I saw it as being a bit of a wart. I use the OpenID plugin for
WordPress as my provider, so it may be that it doesn't do this
correctly. I noticed that Google shows just "pypi.python.org", but the
WordPress plugin shows that return URL instead. Nevertheless, I agree
that it's too late/not worth it to change that now.

> I think there is no way out wrt. to the basic auth prompt. I could
> label the "Login" link "Password login" if you think this would help.

The basic auth prompt doesn't bother me so much as the fact that the 401
doesn't have a "Use OpenID [Google] [myOpenID] [Launchpad]" set of
links; you have to use the brower's back button because the only links
offered are to register or reset your password.

> Preventing the browser from prompting the user on the chance they
> might want to enter an OpenID is not possible, and stopping to use
> basic authentication is not feasible.

In theory, you could catch usernames that started with "http://";, but I
imagine that only "ultra geeks" know their URIs (I have no idea what the
URI for a Google account is). But, I don't see this as being worthwhile
either; I just think it would be nice if the 401 page gave a quick way
to correct one's mistake that didn't involve the back button.

> And again, enjoying a short OpenID URI
> probably does put you in the "ultra geek" category (which I
> seriously don't mean as an offense).

No offense taken. :)

-- 
Scott Dial
[email protected]
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread R. David Murray 
On Sun, 26 Sep 2010 21:56:20 -0400, Scott Dial  
wrote:
> On 9/26/2010 3:12 AM, Martin v. Loewis wrote:
> > Preventing the browser from prompting the user on the chance they
> > might want to enter an OpenID is not possible, and stopping to use
> > basic authentication is not feasible.
> 
> In theory, you could catch usernames that started with "http://";, but I

No, Martin really meant "not possible": once basic auth is started,
the browser prompts for username and password and you are in basic-auth
land thereafter; the web server has *no way* to tell the browser to
*stop* using basic auth.

> imagine that only "ultra geeks" know their URIs (I have no idea what the
> URI for a Google account is). But, I don't see this as being worthwhile

Well, my OpenId is 'david.bitdance.com', so even if you could get around
the basic auth problem, looking for "http://"; wouldn't work.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Martin v. Löwis 
> No, Martin really meant "not possible": once basic auth is started,
> the browser prompts for username and password and you are in basic-auth
> land thereafter; the web server has *no way* to tell the browser to
> *stop* using basic auth.

Yes, but Scott proposed that OpenID users might fill in their OpenID
in the username field and leave the password field empty. Technically,
this would work - the browser would then get the OpenID redirect in
response to the original request.

>> imagine that only "ultra geeks" know their URIs (I have no idea what the
>> URI for a Google account is). But, I don't see this as being worthwhile
> 
> Well, my OpenId is 'david.bitdance.com', so even if you could get around
> the basic auth problem, looking for "http://"; wouldn't work.

Sure - however, it would actually be possible to determine that this is
an OpenID: perform discovery on it. If that succeeds, try to establish
a provider association; if that also succeeds, redirect the user to the
OpenID login process.

However, I'd rather not do that, since OpenID users don't expect that
kind of interface.

Providing OpenID links on the login failure 401 response is reasonable,
though.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python wiki

2010-09-26 Thread Scott Dial 
On 9/26/2010 11:45 PM, R. David Murray wrote:
> On Sun, 26 Sep 2010 21:56:20 -0400, Scott Dial 
>  wrote:
>> On 9/26/2010 3:12 AM, Martin v. Loewis wrote:
>>> Preventing the browser from prompting the user on the chance they
>>> might want to enter an OpenID is not possible, and stopping to use
>>> basic authentication is not feasible.
>>
>> In theory, you could catch usernames that started with "http://";, but I
> 
> No, Martin really meant "not possible": once basic auth is started,
> the browser prompts for username and password and you are in basic-auth
> land thereafter; the web server has *no way* to tell the browser to
> *stop* using basic auth.

I agree that once you reply with a 401 that you will prompt the user,
but my point was what "username" means in the Authorization header is
open to interpretation by the HTTP server and/or script handling the GET
request.

>> imagine that only "ultra geeks" know their URIs (I have no idea what the
>> URI for a Google account is). But, I don't see this as being worthwhile
> 
> Well, my OpenId is 'david.bitdance.com', so even if you could get around
> the basic auth problem, looking for "http://"; wouldn't work.

That's actually not a valid OpenID[1], but the OpenID specification says
a relaying party "MUST" normalize identifiers[2] (in this case,
prepending the "http://";). I believe bugs.python.org does this by
checking for a username first(?), and failing any matches, it normalizes
it for OpenID discovery. Otherwise, I can always use the canonical form
of my ID "http://scottdial.com"; to login (assuming ':' and '/' are
illegal characters for usernames).

I say all this not with the intent of saying pypi *needs* this, but to
refute the notion that OpenID must be clumsy to use.

[1] http://openid.net/specs/openid-authentication-2_0.html
"""
Identifier:
An Identifier is either a "http" or "https" URI, (commonly referred
to as a "URL" within this document), or an XRI (Reed, D. and D. McAlpin,
“Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0].
"""

[2] http://openid.net/specs/openid-authentication-2_0.html#normalization
"""
3.  Otherwise, the input SHOULD be treated as an http URL; if it does
not include a "http" or "https" scheme, the Identifier MUST be prefixed
with the string "http://";. If the URL contains a fragment part, it MUST
be stripped off together with the fragment delimiter character "#". See
Section 11.5.2 (HTTP and HTTPS URL Identifiers) for more information.
"""

-- 
Scott Dial
[email protected]
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com