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
On 9/25/2010 5:37 PM, Martin v. Löwis wrote:
Unfortunately, most sites using OpenID seem have an awkward login
process. Maybe it's just me (I don't use OpenID much) but I expect
that without a lot more handholding of new users, OpenID actually
turns more people away than any other
Keywords are generally better than a restricted vocabulary for richness
of content, but worse for finding the appropriate search term. You pays
yer money and takes yer chance.
I think you are unaware what a roundup keyword is, here.
But without any smarts being applied to the problem
it's
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
On 25 September 2010 23:57, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Sat, Sep 25, 2010 at 9:20 AM, Tim Peters tim.pet...@gmail.com 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
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
On Sun, Sep 26, 2010 at 7:46 AM, Martin v. Löwis mar...@v.loewis.de 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
On Sat, Sep 25, 2010 at 11:15 PM, anatoly techtonik techto...@gmail.com 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
On 26 September 2010 09:01, Paul Moore p.f.mo...@gmail.com wrote:
On 25 September 2010 23:57, Greg Ewing greg.ew...@canterbury.ac.nz 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?
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
On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou solip...@pitrou.net 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
On Sun, Sep 26, 2010 at 13:40, Martin v. Löwis mar...@v.loewis.de 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
On Sun, Sep 26, 2010 at 8:16 AM, Martin v. Löwis mar...@v.loewis.de 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
On Sat, Sep 25, 2010 at 6:20 PM, anatoly techtonik techto...@gmail.com 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
On Sun, Sep 26, 2010 at 13:36, Paul Moore p.f.mo...@gmail.com 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,
On Sep 26, 2010, at 7:36 AM, Paul Moore wrote:
On 26 September 2010 09:01, Paul Moore p.f.mo...@gmail.com wrote:
On 25 September 2010 23:57, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Paul Moore wrote:
Windows has (I believe) user definable filesystems, too, but the OS
has get me the
Am 26.09.2010 13:58, schrieb Nick Coghlan:
On Sun, Sep 26, 2010 at 8:16 AM, Martin v. Löwis mar...@v.loewis.de 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
On 26 September 2010 13:37, James Y Knight f...@fuhm.net 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
On Sun, Sep 26, 2010 at 10:59 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 26.09.2010 13:58, schrieb Nick Coghlan:
On Sun, Sep 26, 2010 at 8:16 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
But that can't work: then off-site links into either wiki break.
Georg isn't suggesting a general
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
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 mar...@v.loewis.de
wrote:
But that can't work: then off-site links into either wiki break.
Georg isn't suggesting a general structural change, just a
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
-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
-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
On Sun, Sep 26, 2010 at 7:58 AM, Tres Seaver tsea...@palladion.com 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
On Sun, Sep 26, 2010 at 06:36, Paul Moore p.f.mo...@gmail.com wrote:
On 26 September 2010 09:01, Paul Moore p.f.mo...@gmail.com wrote:
On 25 September 2010 23:57, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Paul Moore wrote:
Windows has (I believe) user definable filesystems, too, but
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
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
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
Am 26.09.2010 12:54, schrieb Nick Coghlan:
On Sat, Sep 25, 2010 at 9:20 AM, Tim Peters tim.pet...@gmail.com 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
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
Martin v. Löwis martin at 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
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
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
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
*
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
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
On 26 September 2010 19:01, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Martin v. Löwis martin at 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
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
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org 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
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org 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
On Mon, Sep 27, 2010 at 6:56 AM, Guido van Rossum gu...@python.org 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
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,
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
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
P.J. Eby http://mail.python.org/mailman/listinfo/python-devpje
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
P.J. Eby p...@telecommunity.com 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
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
On Sun, 26 Sep 2010 21:56:20 -0400, Scott Dial scott+python-...@scottdial.com
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
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
On 9/26/2010 11:45 PM, R. David Murray wrote:
On Sun, 26 Sep 2010 21:56:20 -0400, Scott Dial
scott+python-...@scottdial.com 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,
51 matches
Mail list logo
